Systems and methods for handling calls associated with an interactive voice response application

ABSTRACT

A method for processing a call is provided. The method includes receiving an inbound call leg via a network device. The inbound call leg is processed using an interactive voice response (IVR) device, and an outbound call leg is generated based on processing the inbound call leg. The outbound call leg is made available to the network device. The inbound call leg and the outbound call leg are handed off from the IVR device to the network device.

FIELD OF THE INVENTION

Implementations consistent with the invention relate generally tocommunication networks and, more particularly, to systems and methodsfor implementing call handoffs associated with an interactive voiceresponse (IVR) application operating in an Internet protocolenvironment.

BACKGROUND OF THE INVENTION

Historically, voice-based telephone communications have been handled viadedicated networks, such as the public switched telephone network(PSTN), while data communications have been handled via dedicated packetnetworks, such as Internet protocol (IP) networks. A current trend is toconverge these two types of networks, where telephone voice traffic andother forms of real-time media are converted into digital form andcarried by a packet data network along with other forms of data Theseconverged networks may offer many advantages, such as lower operatingcosts as compared to maintaining separate voice and data networks,greater flexibility regarding service offerings to customers, such asmultimedia conferencing, and more efficient use of network resources,such as network hardware and software.

Conventional telephones may employ dual-tone multifrequency (DTMF)signals for placing calls to a called party. DTMF techniques assign dualtones to each number on a keypad associated with a telephone handset.When a user depresses a number, a unique dual-tone signal may begenerated. The PSTN uses DTMF signals to route calls through appropriateintermediary devices, such as central offices and switches, to arrive ata desired destination associated with a called party. Converged networksmay employ telephone gateways for converting PSTN signals, such as DTMFsignals, into packetized data for use in a data network, such as theInternet. Telephone gateways may digitize DTMF signals and encode theminto standardized formats for use with portions of the network runningpacket protocols.

Users of converged network telephone services may use DTMF tones fordialing destination phone numbers and for performing other applicationson converged networks. For example, users may require assistance and/orinformation from service providers, corporations, institutions, and/orgovernment agencies using a telephone device. In many instances, a usermay interact with an interactive voice response (IVR) system whileobtaining assistance and/or information.

IVR systems may be used for processing incoming calls. For example, acustomer may call a telephone company to report a problem with atelephone line. The telephone company may employ an IVR system forprocessing incoming calls. When the call is received at the telephonecompany, an IVR system may answer the call and prompt the user to enter,for example, a telephone number associated with a malfunctioning linevia a recorded message. The IVR system may detect a series of DTMFsignals associated with a sequence of digits depressed by the user inresponse to the IVR prompts. Efficiently operating IVR systems mayrequire that operators of these systems attempt to handle calls in acost effective manner.

SUMMARY OF THE INVENTION

In accordance with an aspect of the invention, a first network devicefor establishing a communication session with a destination is provided.The first network device may include, a first network interfaceconfigured to receive a first inbound portion of an inbound call leg,and make the first inbound portion available to a second network device,where the first inbound portion between the first network device and thesecond network device is referred to as a second inbound portion. Thefirst network device may include a second network interface configuredto receive a first outbound portion of an outbound call leg thatoriginates from the second network device, and make the first outboundportion available to the destination, where the first outbound portionbetween the first network device and the destination is referred to as asecond outbound portion. The first network device may include aprocessor operatively associated with the first network interface andthe second network interface. The processor may be configured to makethe second inbound portion available to the second network device,receive the first outbound portion when the second network device hasinteracted with the second inbound portion, and bridge the first inboundportion to the second outbound portion.

In accordance with another aspect of the invention, a media server isprovided. The media server may include an interactive voice response(IVR) module for processing a dual tone multifrequency (DTMF) signalassociated with an inbound call leg. The media server may include afirst network interface for receiving the inbound call leg, and a secondnetwork interface for making an outbound call leg available to a networkdevice. The media server may include a processor configured to make theinbound call leg available to the IVR module, establish the outboundcall leg based on the processing performed by the IVR module, andhandoff the inbound call leg and the outbound call leg to the networkdevice.

In accordance with still another aspect of the invention, a systemconfigured to establish a communication session in a communicationsnetwork is provided. The system may include, a media server having afirst media server port and a second media server port. The system mayinclude a media firewall configured to receive an inbound call leg viathe network, the received inbound call leg being a first inbound callleg, make the inbound call leg available to the first media server portto form a second inbound call leg, receive an outbound call leg from thesecond media server port, the received outbound call leg being a firstoutbound call leg, make the outbound call leg available to a destinationdevice to form a second outbound call leg, and bridge the first inboundcall leg to the second outbound call leg, where the bridging causes themedia server to be removed from the communication session.

In accordance with yet another aspect of the invention, a method forprocessing a call is provided. The method may include receiving aninbound call leg via a network device and processing the inbound callleg using an interactive voice response (IVR) device. The method mayinclude generating an outbound call leg based on processing of theinbound call leg and making the outbound call leg available to thenetwork device. The method may include handing off the inbound call legand the outbound call leg from the IVR device to the network device.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute apart of this specification, illustrate an embodiment of the inventionand, together with the description, explain the invention. In thedrawings,

FIG. 1 illustrates an exemplary system in which systems and methods,consistent with the principles of the invention, may be implemented;

FIG. 2 illustrates an exemplary configuration of a media server in animplementation consistent with the principles of the invention;

FIG. 3 illustrates an exemplary configuration of a media firewall in animplementation consistent with the principles of the invention;

FIGS. 4A and 4B illustrate exemplary implementations for processing acall using a media firewall and a media server consistent with theprinciples of the invention;

FIG. 5 illustrates an exemplary flowchart showing a method forprocessing a call in accordance with an implementation consistent withthe principles of the invention;

FIG. 6 illustrates exemplary signaling that may be used for establishingan inbound leg in an implementation consistent with the principles ofthe invention;

FIG. 7 illustrates exemplary signaling that may be used for establishingan outbound leg in an implementation consistent with the principles ofthe invention;

FIG. 8 illustrates exemplary signaling that may be used for establishinga bridged communication session via a media firewall in animplementation consistent with the principles of the invention; and

FIG. 9 illustrates exemplary signaling that may be used for taking backa bridged communication session from a media firewall in animplementation consistent with the principles of the invention.

DETAILED DESCRIPTION

The following detailed description of implementations consistent withthe principles of the invention refers to the accompanying drawings. Thesame reference numbers in different drawings may identify the same orsimilar elements. Also, the following detailed description does notlimit the invention. Instead, the scope of the invention is defined bythe appended claims and their equivalents.

Implementations consistent with the principles of the invention mayprovide call bridging in IVR applications using media firewall ports inlieu of media server ports. In this way, the media server may be freedup to perform other functions.

EXEMPLARY SYSTEM

FIG. 1 illustrates an exemplary system 100 in which systems and methods,consistent with the principles of the invention, may be implemented. Asillustrated, system 100 may include a data network 102, a telephonenetwork 104, a telephone device 106, a network gateway 108, a servicecontroller 110, a media server 112, a media firewall 114 and a sessioninitiation protocol (SIP) device 116. The number of devices illustratedin FIG. 1 is provided for simplicity. In practice, a typical systemcould include more or fewer devices than illustrated in FIG. 1. Inaddition, devices depicted as single entities in FIG. 1 may beimplemented in a distributed fashion.

Data network 102 may include one or more networks, such as the Internet,an intranet, a local area network (LAN), a metropolitan area network(MAN), a wide area network (WAN), or another type of network that iscapable of transmitting data from a source device to a destinationdevice. Telephone network 104 may include one or more public switchedtelephone networks (PSTNs) or other types of switched networks.Telephone network 104 may also include one or more wireless networks.

Telephone device 106 may include any device capable of making and/orreceiving calls using PSTN compatible signals. For example, telephonedevice 106 may include a plain old telephone system (POTS) handset.Telephone device 106 may include a landline telephone device or awireless telephone device. Telephone device 106 may be implemented as astandalone telephone device or may be integrated with other devices,such as an intercom device, a two-way messaging system, a displayterminal, a personal organizer, etc.

Network gateway 108 may include one or more devices that allow divergenttransport networks to cooperatively carry traffic. Network gateway 108may provide for interoperation between different signaling schemes andbetween different media forms. For example, network gateway 108 mayadapt between SS7 signaling of telephone network 104 and SIP or H.323protocols used by data network 102. At the same time, network gateway108 may adapt analog voice signals in a telephone bearer channel to apacketized data stream suitable for transport over data network 102.Moreover, network gateway 108 may convert DTMF signals into RFC 2833compatible digital representations for use in data network 102.

Service controller 110 may include one or more devices configured tofacilitate control of media server 112 and media firewall 114. Forexample, service controller 110 may operate to coordinate initialrouting of a voice path through media firewall 114 in route to mediaserver 112. In addition, service controller 110 may operate to re-routeor drop inbound call legs to media server 112. Service controller 110may also operate to re-route, or drop, outbound call legs originating atmedia server 112. Implementations of service controller 110 may beconfigured as a SIP application server having proxy server functionalitythat facilitates the establishment of SIP calls and/or location serverfunctionality that provides a repository for end user information toenable, for example, address validation, feature status, and real-timesubscriber feature configuration. SIP is a signaling protocol forinitiating, managing and terminating voice and video sessions acrosspacket networks. SIP may be used to facilitate flexible systemarchitectures capable of handling media types in substantiallyreal-time, such as voice, video, and images.

Media server 112 may include a server configured to receive data, orrequests, from devices such as conventional telephones, SIP device 116,mobile phones, facsimile machines, computers, and/or personal digitalassistants (PDAs). Media server 112 may support advanced processing ofvoice and/or media streams. For example, media server 112 may providefor voice announcements, multi-party conferencing, messaging,text-to-speech (TTS), speech recognition, and IVR.

Media server 112 may employ circuit media via a telephony interface,such as legacy T1, digital signal (DS)-3, and call control protocols,and/or packet media, such as IP media. Media server 112 may utilizeapplication programming interfaces (APIs) and protocols for controllingmedia resources at the server, or platform, level. For example, voiceextensible markup language VoiceXML, speech application language tags(SALT) or Java based APIs, such as S.410 may be used for implementingAPIs. In one implementation, media server 112 may operate to provide IVRcapabilities to a contact center, such as a help desk associated with atelephone company. As used herein, contact center refers to anydestination (e.g., a called party) that uses DTMF signals alone, or incombination with other techniques, for receiving inputs from a callingparty. For example, a contact center may be a financial institution, avoice mail system, an ordering application, a human resourcesapplication, an educational institution and/or a government entity thatemploys DTMF signaling to process a portion of a call received from acalling party. Contact centers may use DTMF signals exclusively, or theymay use DTMF signals in conjunction with other signaling techniques suchas voice recognition, text, and/or specialized signaling devices.

Media firewall 114, also referred to as a session border controller(SBC), may include a device operating as a firewall and/or a signalingand media routing platform. In one implementation, media firewall 114may operate at a network border. For example, media firewall 114 mayoperate at the border of data network 102 to protect media server 112from unauthorized packets. Media firewall 114 may have a public side, orinterface, and a private side, or interface. The public side may becoupled to an unsecured, or untrusted, network such as the Internet,while the private side may be coupled to a trusted network, such as acorporate LAN. Media firewall 114 may allow only authorized packets topass from the public side to the private side. Media firewall 114 may beconfigured to handle network address translation (NAT) traversal issuesso that quality of service (QoS) sensitive applications may be used,such as voice-over-IP (VoIP) and real-time media. Media firewall 114 mayalso be adapted to allow peering with other network devices, such asnetwork gateway 108. Media firewall 114 may support multiple protocols,such as SIP, H.323-signaled real-time protocol (RTP) media, andprocessing of DTMF signals.

Media firewall 114 may be implemented as a media pivot in oneimplementation. Media pivot, as used herein, refers to a device capableof performing DTMF detection and/or bridging an input port to an outputport. For example, a media pivot may be implemented in software toprovide DTMF detection at a low per-port cost as compared with mediafirewall ports and/or media server ports.

SIP device 116 may include any client (e.g., a computer device, aweb-appliance, etc.) that is configured to provide SIP telephonefunctions. SIP device 116 may be implemented in a standalone device,such as a dedicated SIP phone, and/or SIP device 116 may be incorporatedwith other devices such as a SIP/PSTN-hybrid phone. SIP device 116 mayalso include a software client that may run, for example, on aconventional personal computer (PC), laptop computer, or personaldigital assistant (PDA).

Although implementations consistent with the principles of the inventionare described below in the context of a SIP and/or an IP-based network,one of ordinary skill in the art will recognize that implementationsconsistent with the invention may be generally applicable to otherequivalent or analogous communication protocols (e.g., InternationalTelecommunication Union (ITU) H.323) and/or types of transport networks(e.g., asynchronous transfer mode (ATM), frame relay, etc.). Both theITU H.323 standard and the IETF's SIP are examples of protocols that maybe used for establishing a communications session among terminals, suchas telephone-like devices that may be connected to a network. The SIPprotocol is described in IETF document RFC 2543 and its successors (RFC3261 et al.).

FIG. 2 illustrates an exemplary configuration of media server 112 in animplementation consistent with the principles of the invention. It willbe appreciated that network gateway 108, service controller 110, and SIPdevice 116 may be similarly configured. As illustrated, media server 112may include a bus 210, a processor 220, a memory 230, a read only memory(ROM) 240, a storage device 250, an input device 260, an output device270, and a communication interface 280. Bus 210 may include one or moreconventional buses that permit communication among the components ofmedia server 112.

Processor 220 may include any type of conventional processor ormicroprocessor that interprets and executes instructions. Memory 230 mayinclude a random access memory (RAM) or another type of dynamic storagedevice that stores information and instructions for execution byprocessor 220. Memory 230 may also be used to store temporary variablesor other intermediate information during execution of instructions byprocessor 220.

ROM 240 may include a conventional ROM device and/or another type ofstatic storage device that stores static information and instructionsfor processor 220. Storage device 250 may include a magnetic disk oroptical disk and its corresponding drive and/or some other type ofmagnetic or optical recording medium and its corresponding drive forstoring information and/or instructions.

Input device 260 may include any conventional mechanism or combinationof mechanisms that permits the operator to input information to mediaserver 112, such as a keyboard, a mouse, a microphone, a pen-basedpointing device, a biometric input device, such as a voice recognitionand/or a finger print scanning device. Output device 270 may include anyconventional mechanism or combination of mechanisms that outputsinformation to the operator, including a display, a printer, a speaker,etc.

Communication interface 280 may include any transceiver-like mechanismthat enables media server 112 to communicate with other devices and/orsystems, such as media firewall 114. For example, communicationinterface 280 may include a modem and/or an Ethernet interface or port.Alternatively, communication interface 280 may include other mechanismsfor communicating via a data network, such as network 102.

Media server 112 may implement the functions described below in responseto processor 220 executing software instructions contained in acomputer-readable medium, such as memory 230. A computer-readable mediummay be defined as one or more memory devices and/or carrier waves. Inalternative embodiments, hardwired circuitry may be used in place of orin combination with software instructions to implement featuresconsistent with the principles of the invention. Thus, implementationsconsistent with the principles of the invention are not limited to anyspecific combination of hardware circuitry and software.

FIG. 3 illustrates an exemplary configuration of media firewall 114 inan implementation consistent with the principles of the invention. Mediafirewall 114 may include a bus 310, a processor 320, a memory 330 and acommunication interface 340. It will be appreciated that media firewall114 may include additional components that aid in receiving, processing,and/or transmitting data.

Bus 310 may include one or more conventional buses that permitcommunication among the components of media firewall 114. Processor 320may include any type of conventional processor or microprocessor thatinterprets and executes instructions. Memory 330 may include a RAM oranother type of dynamic storage device that stores information andinstructions for execution by processor 320. Memory 330 may also be usedto store temporary variables or other intermediate information duringexecution of instructions by processor 320.

Communication interface 340 may include any transceiver-like mechanismthat enables media firewall 114 to communicate with other devices and/orsystems, such as media server 112. For example, communication interface340 may include a network interface card (NIC), a communications port, ahardwired connection, etc. Alternatively, communication interface 340may include other mechanisms for communicating via a data network, suchas network 102.

Media firewall 114 may implement the functions described below inresponse to processor 320 executing software instructions contained in acomputer-readable medium, such as memory 330. In alternativeembodiments, hardwired circuitry may be used in place of or incombination with software instructions to implement features consistentwith the principles of the invention. Thus, implementations consistentwith the principles of the invention are not limited to any specificcombination of hardware circuitry and software.

Exemplary Call Handling

In implementations consistent with principles of the invention, mediafirewall 114 may receive an inbound call from a user, such as a user oftelephone device 106, and pass the inbound call to media server 112.Media firewall 114 may also receive outbound calls from media server 112and pass them on to other devices and/or users on a network, such as acontact center, or a gateway. Media firewall 114 may further performcall handoffs with media server 112, where media firewall 114 bridges aninbound call leg with an outbound call leg using one or more portsand/or a bridging technique. Implementations consistent with principlesof the invention, may free up media server ports through the use ofbridged media firewall ports. The free media server ports may beavailable to service additional inbound call legs.

FIGS. 4A and 4B illustrate exemplary implementations for processing acall using a media firewall and a media server consistent with theprinciples of the invention. The implementation of FIG. 4A may include amedia firewall 114 having one or more media firewall ports 402-1 to402-M (collectively firewall ports 402), a media server 112 having anIVR module 406 and one or more media server ports 404-1 to 404-N(collectively server ports 404), an inbound call leg 405 (referred to asinbound leg 405), and an outbound call leg 410 (referred to as outboundleg 410). The portion of inbound call leg 405 between media firewall 114and media server 112 will be referred to hereinafter as portion A, andthe portion of outbound call leg 410 between media firewall 114 andmedia server 112 will be referred to hereinafter as portion B.

Media firewall. 114 may receive inbound leg 405 from network 102 vianetwork gateway 108. An inbound leg may consist of a calling sessionoriginated by telephone device 106 and/or SIP device 116. For example, auser may place a call to a contact center to obtain assistance. Thecontact center may be operatively associated with IVR module 406. Theuser's call may arrive at media firewall 114 as an inbound leg 405having a destination associated with IVR module 406 on media server 112.Inbound leg 405 may arrive at a network interface, such as firewall port402-1. Media firewall 114 may pass inbound leg 405 to a networkinterface associated with media server 112, such as server port 404-1,as portion A. Portion A and B refer to portions of an inbound oroutbound call leg, respectively. Portion A and B may be carried over alink; however, the terms portion A and portion B are not intended torefer to the physical link itself, but rather refer to data exchangedbetween media firewall 114 and media server 112 over a link connectingthem.

Media server 112 may process inbound leg 405 using IVR module 406. IVRmodule 406 may play, for example, recorded messages asking the user toinput DTMF signals using a keypad associated with telephone device 106.IVR module 406 may process the DTMF signals generated by the sequence ofdigits depressed by the user (referred to as a digit sequence). Based onthe digit sequence, IVR module 406 may, for example, route inbound leg405 to an operator associated with the contact center. For example, IVRmodule 406 may route the user to a customer service representative afteridentifying the digit sequence received from the user. The user maycarry on a conversation with the customer service representative tofacilitate processing of the user's request.

The customer service representative may determine that inbound leg 405should be routed to another destination to further process the user'srequest. The customer service representative may dial a sequence ofdigits associated with a forwarded destination. Forwarded destinationmay refer to a calling destination that is contacted after an initialinbound leg is processed by an initial destination, which, in theexample above, is the customer service representative. For example, IVRmodule 406 may detect the DTMF signals received from the customerservice representative (initial destination) and generate an outboundleg 410 for connecting the user with a forwarded destination.

Media server 112 may originate outbound leg 410 using a server port,such as server port 404-2. Outbound leg 410 may be routed through a portof media firewall 114 in route to the forwarded destination. Forexample, outbound leg 410 may be connected to firewall port 402-2. Mediafirewall 114 may direct outbound leg 410 to the forwarded destinationusing firewall port 402-2.

Media servers, such as media server 112, may run complex softwareapplications that interact with numerous interfaces, such as serverports 404. For example, a media server may run multiple IVRapplications, text-to-speech (TTS) applications, call forwardingapplications, messaging applications, and multimedia applications inconjunction with numerous server ports 404. This complexity may resultin relatively high per-port costs for media server ports, such as serverports 404-1 to 404-N. If server ports 404 are not used efficiently,operating costs may remain above a desired level.

For example, a calling session may consist of the activities shown inTable 1, each taking the indicated amount of time on a respective mediaserver port 404-1 to 404-N. In this example, assume an inbound leg isreceived on a first media server port (e.g., server port 404-1) and anoutbound leg is originated using a second media server port (e.g.,server port 404-2).

TABLE 1 Exemplary Port Usages for a Media Server Operating on an InboundCall Leg Server Port Action Usage (sec) User interacting with IVR systemusing DTMF signals  10 (1^(st) port) (inbound leg) User interacting withcustomer service representative  60 (1^(st) port) (inbound leg) Customerservice representative interacting with IVR  10 (1^(st) port) using DTMFsignals to place call to forwarded  10 (2^(nd) port) destination(inbound leg and establishing outbound leg) User interacting withforwarded destination 300 (1^(st) port) (inbound leg and outbound leg)300 (2^(nd) port) Respective port usages 380 (1^(st) port) 310 (2^(nd)port)In the above example, server port 404-1 may be used for 380 seconds andserver port 404-2 may be used for 310 seconds. In this example, twomedia server ports are used for 300 seconds to connect the user to acalled party (e.g., an operator or technical specialist) at theforwarded destination. Since media server ports may be expensive, tyingup server ports for connecting calls not requiring significant DTMFsignal detection may be undesirable. Implementations consistent with theprinciples of the invention may reduce the amount of time that serverports are needed when handling calls.

FIG. 4B illustrates a further aspect of the exemplary implementation ofFIG. 4A. When media firewall 114 passes outbound leg 410 from mediaserver 112 to a forwarded destination, media firewall 114 may dropportion A of inbound leg 405 and portion B of outbound leg 410.

Media firewall 114 may maintain the call between the user and theforwarded destination by bridging the firewall port associated with theinbound leg to the firewall port associated with the outbound leg. Forexample, media firewall 114 may use bridge 408 to connect inbound leg405 associated with firewall port 402-1 to outbound leg 410 associatedwith firewall port 402-2. Bridge 408 may be implemented in hardware,software, and/or a combination of hardware and software. The handofffrom media server 112 to media firewall 114 may be transparent to theuser and to an operator at a destination. The handoff of portion A andportion B may be controlled in whole or in part by service controller110.

In one implementation, media firewall 114 may bridge firewall port 402-1to firewall port 402-2 based on a handoff message received from mediaserver 112 and/or service controller 110. When firewall port 402-1 and402-2 are bridged, a user may participate in a communication sessionwith a forwarded destination using the bridged communication session.Bridged communication session refers to a call, or communicationsession, routed through media firewall 114 without requiring substantialongoing DTMF monitoring and/or intervention by other network devices,such as media server 112.

By way of comparison, the call example illustrated in Table 1 used onemedia server port (404-1) for 380 seconds and another media server port(404-2) for 310 seconds. An implementation consistent with theprinciples of the invention may employ a bridged communication sessionwhere media firewall 114 bridges an inbound leg and an outbound legtogether to remove media server 112 from a portion of the calling, orcommunication, session. For example, referring to the example associatedwith Table 1, the port usages shown in Table 2 may be realized whenusing a bridged communication session in conjunction with media firewall114.

TABLE 2 Exemplary Port Usages for a Media Firewall and a Media Serverusing a Bridged Communication Session Server Port Firewall Port ActionUsage (sec) Usage (sec) User interacting with IVR system using 10(1^(st) port)  10 (1^(st) port) DTMF signals (inbound leg) Userinteracting with customer service 60 (1^(st) port)  60 (1^(st) port)representative (inbound leg) Customer service representative 10 (1stport)  10 (1st port) interacting with IVR using DTMF signals 10 (2^(nd)port)  10 (2^(nd) port) to place call to forwarded destination (inboundleg and outbound leg) User interacting with forwarded  0 (1st port) 300(1^(st) port) destination (bridged communication  0 (2^(nd) port) 300(2^(nd) port) session) Respective port usages 80 (1^(st) port) 380(1^(st) port) 10 (2^(nd) port) 310 (2^(nd) port)

Media server port usage may be reduced from 380 seconds to 80 secondsfor a first port associated with an inbound leg and from 310 seconds to10 seconds for a second port associated with an outbound leg. As seenfrom these examples, significant reductions in media server port usagemay be realized when media firewall 114 bridges an inbound leg to anoutbound leg and performs DTMF signal detection on the bridged callingsession.

Referring back to FIG. 4B, media firewall 114 may monitor the bridgedcommunication session for DTMF signals. When a DTMF signal is detected,media firewall 114 may process the signal before reestablishing inboundleg 405 (i.e., portion A) and/or outbound leg 410 (i.e., portion B) withmedia server 112, or media firewall 114 may reestablish inbound leg 405and/or outbound leg 410 with media server 112 whenever a DTMF tone isdetected. Media server 112 may process DTMF signals when media firewall114 does not process DTMF signals, or both media firewall 114 and mediaserver 112 may process a DTMF signal.

Media firewall 114 may detect DTMF signals using digital signalprocessing (DSP) techniques known in the art and/or by looking forencoded DTMF signals within packets passing through firewall ports 402.For example, DTMF signals may be encoded in IP packets using industrystandard protocols, such as RFC 2883. Use of encoded DTMF signals inpackets facilitates efficient and inexpensive monitoring for DTMFsignals since DSP cards and/or interfaces may not be required.

Implementations of modern contact centers may employ a technique called“take back and transfer” (TNT). TNT allows a destination, such as theforwarded destination, to transfer a call back to media server 112and/or another destination, such as in call forwarding or conferencecalling. TNT may be accomplished using a special sequence of DTMFsignals. For example, TNT may be initiated when a party dials “*8” usinga keypad associated with a telephone device. When a processing devicedetects DTMF signals associated with *8, inbound leg 405 may beconnected to IVR module 406 using a server port 404-1 to 404-N by way ofTNT inbound leg 415. Dialing *8 may further cause the forwardeddestination to be connected to IVR module 406 by way of TNT outbound leg420. A processing device associated with firewall 114 and/or mediaserver 112 may monitor the duration of the bridged communication sessionto ensure that TNT digit sequences are promptly detected.

Implementations consistent with the principles of the invention mayimplement processing functions associated with DTMF signal detection,including TNT, in media firewall 114. Implementing DTMF signal detectionin media firewall 114 may have advantages as compared to performing TNTdetection in media server 112. For example, performing DTMF signaldetection in media firewall 114 may associate DTMF detection with portshaving lower costs, as compared to media server ports, and/or performingDTMF signal detection in media firewall 114 may reduce the amount oftime that media server ports are used to monitor calls.

Exemplary Method

FIG. 5 illustrates an exemplary flowchart showing a method forprocessing a call in accordance with an implementation consistent withprinciples of the invention. Processing may begin with media firewall114 receiving an incoming call using inbound leg 405 (act 502). Forexample, a user may call a contact center for help with troubleshootinga problem associated with a personal computer. It is assumed for thisexample that the user places the call using telephone device 106.

Media firewall 114 may connect inbound leg 405 to a server port 304-1 to304-N associated with a media server 112 (act 504). For example, mediafirewall 114 may connect inbound leg 405 to server port 404-1.

Media server 112 may perform IVR interactions on inbound leg 405 usingIVR module 406 (act 506). For example, IVR module 406 may request thatthe user enter a customer number or a serial number associated with thebroken computer. In response to the request, the user may enter a digitsequence by, for example, entering the appropriate digits on telephonedevice 106. Media server 112 may receive and process DTMF signalsproduced by the user entering the digit sequence and perform an actionbased on the processing. For example, IVR module 406 may connect theuser with a customer service representative after processing DTMFsignals received from the user. The customer service representative mayask the user to provide details about a problem with the computer.Assume, for example, that the user has described a problem associatedwith the operating system of the computer in response to questions askedby the customer service representative. The customer servicerepresentative may determine that the user needs to be connected to aspecialist having expertise with the particular operating system runningon the user's computer. The customer service representative may dial asequence of digits associated with the appropriate specialist, and IVRmodule 406 may detect the DTMF signals generated by the customer servicerepresentative.

In response, media server 112 may establish an outbound leg 410 using aserver port and a port associated with firewall 114 (act 508). Mediaserver 112 may establish outgoing leg 410 so as to connect the user withthe specialist, located at a forwarded destination. In oneimplementation, outbound leg 410 may be established using differentports on media server 112 and media firewall 114 than were used forinbound leg 405. Assume, for example, that outbound leg 410 isestablished using server port 404-2 and firewall port 402-2.

Media firewall 114 may bridge inbound leg 405 with outbound leg 410using bridge 408 (act 510). Media firewall 114 may bridge firewall port402-1 to firewall port 402-2 and may drop portion A of inbound leg 405and portion B of outbound leg 410 (See FIG. 4A). The handoff from mediaserver 112 to media firewall 114 may be transparent to the user, theoperating system specialist, and/or the forwarded destination.

Media firewall 114 may monitor inbound leg 405 and/or outbound leg 410for DTMF signals (act 512). When a DTMF signal is detected, mediafirewall 114 may handoff inbound leg 405 and/or outbound leg 410 tomedia server 112 using TNT inbound leg 415 and/or TNT outbound leg 420(act 514). For example, media firewall 114 may support a bridgedcommunication session between the user and the operating systemspecialist using firewall port 402-1, firewall port 402-2, and bridge408. Media firewall 114 may detect a DTMF signal including a digitsequence, such as “*8”. When *8 is detected, media firewall 114 mayreestablish inbound leg 405 and/or outbound leg 410 with media server112 via TNT inbound leg 415 and/or TNT outbound leg 420, respectively.

Media server 112 may perform additional processing of inbound leg 405 oroutbound leg 410 using IVR module 406 (act 516). Media server 112 mayalso process the retrieved legs using other techniques, such as by usinga human operator, a TTS module and/or a voice recognition module. Mediaserver 112 may connect inbound leg 405 and/or outbound leg 410 to anadditional outbound leg for establishing a call with a second forwardeddestination.

For example, the customer service representative may determine that theuser was able to solve only a portion of the computer problem byspeaking with the operating system specialist. The customer servicerepresentative may determine that the user needs to speak with theoperating system specialist and a hardware specialist simultaneously.Media server 112 may keep inbound leg 405 and outbound leg 410 activewhile initiating a second outbound leg to the hardware specialist. Aftermaking contact with the hardware specialist, media server 112 mayhandoff inbound leg 405, outbound leg 410 and the second outbound leg tomedia firewall 114. Media firewall 114 may bridge all three legstogether in a conference call using one or more bridges operating inconjunction with firewall ports 402. Media firewall 114 may monitor thebridged legs for DTMF signals. If DTMF signals are detected, mediafirewall 114 may hand off inbound leg 405, outbound leg 410 and/or thesecond outbound leg to media server 112.

Exemplary Call Flow for Inbound Leg

FIG. 6 illustrates exemplary signaling that may be used for establishingan inbound leg 405 in an implementation consistent with the principlesof the invention. The exemplary signaling flow of FIG. 6 may includenetwork gateway 108, service controller 110, media server 112 and mediafirewall 114.

To initiate the signaling flow of FIG. 6, service controller 110 mayreceive an INVITE request 602 from network gateway 108 in response to auser dialing a sequence of digits. INVITE request 602 may indicate thatthe called party is being invited to participate in a session. TheINVITE request 602 may provide the called party with enough informationto join the session. For example, INVITE request 602 may include asession description protocol (SDP) portion. SDP is a short structuredtextual description of the name and purpose of the session, and themedia, protocols, codec formats, timing and transport information thatare used to decide whether a session is likely to be of interest. SDPmay further include information for informing the called device how tostart media tools to participate in the session. INVITE request 602 mayalso indicate the type of media that the calling party's telephonedevice 106 is able to receive and/or possibly the media that the callingparty's telephone device is willing to send.

In response to INVITE request 602, service controller 110 may transmit acreate resource command (CRR) 604 to media firewall 114. Media firewall114 may respond with a CRR response 606. CRR response 606 may includeinformation relating to source and destination firewall ports. Forexample, CRR response 606 may include an address associated with sourceand destination firewall ports. The source port may include a port towhich an inbound leg may be established and the destination port mayinclude a port from which an inbound leg may be established betweenmedia firewall 114 and media server 112. This port information may beused to construct an SDP that is included in an INVITE message 608 thatmay be sent from service controller 110 to media server 112. Mediaserver 112 may use the media firewall source port information associatedwith inbound leg 405 to construct an SDP for inclusion in a 200 OKresponse message 610 sent from media server 112 to service controller110. The 200 OK response message 610 may indicate that the INVITEmessage 608 was successfully received and acknowledged and may includemedia server port information to which the inbound leg is to beestablished.

Service controller 110 may respond to the 200 OK response 610 with anacknowledgement (ACK) message 612 indicating that the 200 OK message 610was received. Service controller 110 may send a 200 OK response 614 tonetwork gateway 108. 200 OK response 614 may include informationrelating to the media firewall source port. Network gateway 108 mayacknowledge receipt of the 200 OK response 614 with an ACK message 616.The above signaling may result in an inbound leg 405 being establishedbetween network gateway 108 and media firewall 114, via a source portassociated with media firewall 114, and between media firewall 114 andmedia server 112, via a destination port associated with media firewall114. Inbound leg 405 may include an RTP session for facilitating voicecommunication.

Exemplary Call Flow for Outbound Leg

FIG. 7 illustrates exemplary signaling that may be used for establishingan outbound leg 410 in an implementation consistent with the principlesof the invention. The exemplary signaling of FIG. 7 may include networkgateway 108, service controller 110, media server 112 and media firewall114. Inbound leg 405 may exist when the signaling of FIG. 7 commences.

Service controller 110 may send a CRR message 702 to media firewall 114.Media firewall 114 may respond with a CRR response 704 that may includeinformation about source and destination firewall port to be used foroutbound leg 410. CRR response 704 may be sent from firewall 114 toservice controller 110. Service controller 110 may send an INVITErequest 706 to network gateway 108. INVITE request 706 may include anSDP containing information about media firewall 114. The SDP of INVITErequest 706 may include, for example, information about the type ofsession being requested. INVITE request 706 may be directed to a deviceassociated with a forwarded destination. For example, INVITE request 706may be directed to a telephone device associated with the operatingsystem specialist associated with the example discussed in conjunctionwith FIG. 5.

Service controller 110 may receive a 200 OK message 708 from networkgateway 108. 200 OK response 708 may indicate that INVITE request 706was successfully received and acknowledged and may include gateway portinformation to which outbound leg 410 is to be established. Servicecontroller 110 may respond to 200 OK response 708 with an ACK response710. ACK response 710 may constitute an acknowledgement that the 200 OKresponse 708 was received by service controller 110. ACK response 710may also act as the final message exchange between network gateway 108and service controller 110 when establishing an outbound call leg.

Service controller 110 may send an INVITE message 712 to media server112. INVITE message 712 may include an SDP containing information aboutthe requested session. For example, the SDP may include informationabout firewall 114 being used to establish the outbound leg. Forexample, the SDP may include information identifying a destination portassociated with media firewall 114. Media server 112 may respond toreceipt of INVITE message 712 by sending a 200 OK message 714. 200 OKmessage 714 may indicate that E message 712 was successfully receivedand may identify a port on media server 112 from which outbound leg 410is to be established. Service controller 110 may respond to receipt ofthe 200 OK message 714 by sending an ACK message 716. ACK message 716may operate as a final handshake in the message exchange between servicecontroller 110 and media server 112 before establishing outbound leg 410using media firewall 114.

Exemplary Call Flow for Bridging a Call

FIG. 8 illustrates exemplary signaling that may be used for establishinga bridged communication session via a media firewall in animplementation consistent with the principles of the invention. Theexemplary signaling of FIG. 8 may include network gateway 108, servicecontroller 110, media server 112 and media firewall 114. An inbound leg405 and an outbound leg 410 may exist at the completion of the signalingflow of FIG. 7.

Processing may begin with service controller 110 receiving a messagerequesting that one or more call legs be released from media server 112.For example, an application server residing on network 102 may contactservice controller 110 and request that portion A of inbound leg 405 andportion B of outbound leg 410 be released. The application server maysend a release message 802 to service controller 110 to initiate therelease of portion A and portion B of the respective call legs. Servicecontroller 110 may issue a response message 804 to the applicationserver indicating that the release message 802 has been received.

Service controller 110 may issue an inbound leg 405 BYE request 806 tomedia server 112. Inbound leg 405 BYE request 806 may includeinformation useful for effectuating the release of portion A of inboundleg 405. Media server 112 may respond with an inbound leg 405 200 OKresponse 808 to acknowledge that BYE request 806 was received. Servicecontroller 110 may issue an outbound leg 410 BYE request 810 to mediaserver 112. Outbound leg 410 BYE request 810 may include informationuseful for effectuating the release of portion B of outbound leg 410.Media server 112 may respond with an outbound leg 410 200 OK response812 to acknowledge that BYE request 810 was received.

Service controller 110 may send an INVITE request 814 to network gateway108 regarding outbound leg 410. For example, INVITE request 814 mayinclude a SDP containing information about retaining inbound leg 405during and/or after portion A is dropped and bridge 408 is in place forthe call. INVITE request 814 may operate as a re-invitation sent fromservice controller 110 to network gateway 108 to reestablish outboundleg 410 via bridge 408. Implementations may include a re-invitation forinbound leg 405 in addition to, or in lieu of, the re-invitation foroutbound leg 410.

Network gateway 108 may respond to INVITE request 814 with a 200 OKresponse 816. 200 OK response 816 may indicate that INVITE request 814was received by network gateway 108 and may include informationidentifying the gateway port to which outbound leg 410 is established.Service controller 110 may respond with an ACK response 818 toacknowledge receipt of the 200 OK response 816. ACK response 818 may actas the final handshake in the exchange between network gateway 108 andservice controller 110.

Portion A of inbound leg 405 and portion B of outbound leg 410 may bedropped after the message exchange (messages 814-818) between servicecontroller 110 and network gateway 108. Bridge 408 may be employed tomaintain connectivity between inbound leg 405 and outbound leg 410 usingone or more firewall ports. Firewall 114 may monitor inbound leg 405 andoutbound leg 410 for DTMF signals while bridge 408 is in place as setforth above with respect to FIG. 4.

Exemplary Call Flow for Un-Bridging a Call

FIG. 9 illustrates an exemplary signaling that may be used for takingback a bridged connection from a media firewall in an implementationconsistent with the principles of the invention. The exemplary signalingof FIG. 9 may include network gateway 108, service controller 110, mediaserver 112 and media firewall 114. A bridged call may exist after thesignaling flow illustrated in FIG. 8. Assume that media firewall 114detects a DTMF signal on inbound leg 405 and/or outbound leg 410. Thesignaling flow illustrated in conjunction with FIG. 9 may be implementedupon detection of the DTMF signal by media firewall 114.

Media firewall 114 may detect a DTMF signal and send a notify-DTMF(NTF-DTMF) message 902 to service controller 110. NTF-DTMF message 902may include information about the leg on which the DTMF signal wasdetected and information about the digit sequence responsible for theDTMF signals. Service controller 110 may respond with a notify-responsemessage 904. Service controller 110 may send a CRR message 906 to mediafirewall 114. Media firewall 114 may respond with a CRR response 908.CRR response 908 may include information about the firewall portsrequired to establish TNT inbound leg 415 and/or TNT outbound leg 420with media server 112.

Media firewall 114 may send an INVITE request 910 to network gateway108. INVITE request 910 may include an SDP containing information abouta call leg that will be reconnected to media server 112 using one of theTNT legs. In one implementation, the SDP may include informationidentifying a source port of media firewall 114 with which the leg isassociated. INVITE request 910 may operate as a re-invitation requestfor outbound leg 410. INVITE request 910 may cause outbound leg 410 tobe associated with a new and/or separate port on media firewall 114 whencommunicating with media server 112. Implementations may employ are-invitation request associated with inbound leg 405 if desired. Forexample, a re-invitation request may cause inbound leg 405 to becomeassociated with a new and/or separate port on media firewall 114.

Network gateway 108 may respond with a 200 OK response 912 indicatingthat INVITE request 910 was received and understood. In oneimplementation, 200 OK response 912 may include information identifyinga port of gateway 108. Media firewall 114 may respond to receipt of 200OK response 912 with an ACK response 914.

Service controller 110 may send an INVITE message 916 to media server112. INVITE message 916 may include an SDP containing information aboutthe firewall ports used for establishing TNT legs to media server 112.For example, the SDP may include information pertaining to an invitationfor connecting inbound leg 405 to a session with media server 112. Mediaserver 112 may respond by sending a 200 OK 918 message to servicecontroller 110. 200 OK message 918 may indicate that INVITE message 916was received and understood by media server 112 and may includeinformation identifying the port of media server 112 to which inboundleg 305 is to be established. Service controller 110 may send an ACKmessage 920 to indicate that the 200 OK message 918 was received.

Media server 112 may generate and send an INVITE message 922 to sessioncontroller 110. INVITE message 922 may include an SDP containinginformation about a call leg associated with one or more TNT legs. Forexample, the SDP of INVITE message 922 may include information forassociating outbound leg 410 with TNT leg 420 and/or information about aserver port used for receiving TNT leg 420. Service controller 110 mayrespond to INVITE message 922 by sending a 200 OK message 924 to mediaserver 112. 200 OK message 924 may indicate that INVITE message 922 wasreceived and understood and may identify the port of media server 112from which outbound leg 410 is to be established. Media server 112 maysend an ACK message 926 to service controller 110 to acknowledge receiptof 200 OK message 924. ACK message 926 may act as a final handshakemessage in the exchange between media server 112 and session controller110.

TNT leg 415 and/or TNT leg 420 may be established between firewall 114and media server 112 using firewall ports 402 and media server ports404. After establishing TNT legs 415 and 420, IVR module 406 may operateon inbound leg 405 and/or outbound leg 410 to further process DTMFsignals associated with the calling session.

Implementations consistent with the principles of the inventionemploying signaling flows, such as those illustrated in FIGS. 6-9, mayreduce the amount of time media server ports are used to support aparticular calling session. In particular, implementations may operateto substantially restrict use of media server ports to those portions ofa call requiring DTMF signal processing and/or IVR interaction. As aresult, implementations may enable a given number of media server portsto service a larger number of calls than might be possible if mediafirewall 114 did not operate to bridge an inbound call leg to anoutbound call leg.

Implementations consistent with the principles of the invention may beused to facilitate re-origination requests using, for example, pre-paidcalling cards. For example, a user may make a first call using anaccount number associated with, for example, a conventional calling cardand/or a pre-paid calling card. At the end of the first call, the usermay dial a special digit sequence, such as “**2.” The DTMF signalscreated by the digit sequence **2 may act as a re-origination request.The re-origination request may let the user dial a new number associatedwith a called party without hanging up the handset and/or without havingto re-enter information about the calling card, such as a serial number,an account number, and/or authorization number. Media firewall 114 maydetect **2 and cause portion B to be dropped, cause media server 112 toestablish a new outbound leg, and cause firewall 114 to drop portion Aand B after bridging the new outbound leg with the current inbound leg.

Implementations consistent with the principles of the invention may beused to facilitate enhanced call routing features, such as callforwarding, call take back, call give back, and signal transfer. Theseenhanced call routing features may be facilitated using media firewall114 and DTMF signal detection and/or processing associated with one ormore media firewall ports.

CONCLUSION

Systems and methods, consistent with the principles of the invention,allow for the handoff of call legs from a media server to a mediafirewall to thereby free up the media server to perform other functions.

The foregoing description of exemplary embodiments of the inventionprovides illustration and description, but is not intended to beexhaustive or to limit the invention to the precise form disclosed.Modifications and variations are possible in light of the aboveteachings or may be acquired from practice of the invention. Forexample, while series of acts have been described with respect to FIGS.5-9, the order of the acts may be varied in other implementationsconsistent with the invention. Moreover, non-dependent acts may beimplemented in parallel.

No element, act, or instruction used in the description of theapplication should be constructed as critical or essential to theinvention unless explicitly described as such. Also, as used herein, thearticle “a” is intended to include one or more items. Where only oneitem is intended, the term “one” or similar language is used. Further,the phrase based on is intended to mean based, at least in part, onunless explicitly stated otherwise.

The scope of the invention is defined by the claims and theirequivalents.

What is claimed is:
 1. A first network device for establishing acommunication session between a calling party and a destination, thefirst network device comprising: a first network interface to: receive,from the calling party, a first inbound portion of an inbound call leg,and transmit, to a second network device, a second inbound portion ofthe inbound call leg; a second network interface to: receive, from thesecond network device, a first outbound portion of an outbound call legthat connects the calling party with the destination, and transmit, tothe destination, a second outbound portion of the outbound call leg; anda processor operatively associated with the first network interface andthe second network interface, the processor to: cause the first networkinterface to transmit the second inbound portion to the second networkdevice, cause the second network interface to receive the first outboundportion when the second network device has interacted with the secondinbound portion, and bridge the first inbound portion to the secondoutbound portion, in response to detecting a particular dual tonemultifrequency (DTMF) signal, to maintain connectivity, where whenbridging the first inbound portion to the second outbound portion, theprocessor is to: cause the second inbound portion to be dropped inresponse to a BYE request associated with the second inbound portion,and cause the first outbound portion to be dropped in response to a BYErequest associated with the first outbound portion.
 2. The first networkdevice of claim 1, where the processor bridges the first inbound portionto the second outbound portion in response to a bridging instructionreceived from the first network device or a third network device.
 3. Thefirst network device of claim 1, where the first network device includesa firewall device and the second network device includes an interactivevoice response system.
 4. The first network device of claim 3, where theinteractive voice response system is associated with a contact center.5. The first network device of claim 1, where the inbound call leg isassociated with an INVITE request processed by the second networkdevice.
 6. The first network device of claim 1, where the processor isfurther to: detect a second DTMF signal associated with at least one ofthe inbound call leg or the outbound call leg.
 7. The first networkdevice of claim 6, where the processor is further to: cause at least oneof the second inbound portion or the first outbound portion to bere-established when the second DTMF signal is detected.
 8. The firstnetwork device of claim 7, where the second DTMF signal is associatedwith a calling card.
 9. A device-implemented media server comprising: aninteractive voice response (IVR) module to process a dual tonemultifrequency (DTMF) signal associated with an inbound call leg from acaller; a first network interface to receive the inbound call leg; asecond network interface to transmit, in response to an INVITE request,an outbound call leg to a network device; and a processor to: cause thefirst network interface to transmit the inbound call leg to the IVRmodule, cause the second network interface to transmit the outbound callleg to the network device, based on the processing performed by the IVRmodule, where the outbound call leg connects the caller to a destinationthat is communicatively connected to the caller by the network device,handoff the inbound call leg and the outbound call leg to the networkdevice, and reconnect to at least one of the inbound call leg or theoutbound call leg when a second DTMF signal, associated with at leastone of the inbound call leg or the outbound call leg, is detected. 10.The media server of claim 9, where the processor is further to: handoffthe incoming call leg in response to a BYE request associated with theinbound call leg, and handoff the outbound call leg in response to a BYErequest associated with the outbound call leg.
 11. The media server ofclaim 9, where the network device includes a firewall.
 12. The mediaserver of claim 9, where the inbound call leg and the outbound call legare associated with a packet network.
 13. A system to establish acalling session in a communications network, the system comprising: adevice-implemented media server having a first media server port and asecond media server port; a device-implemented media firewall to:receive, at a first media firewall port, a first inbound call legportion of an inbound call leg via the network, transmit, to the firstmedia server port, a second inbound call leg portion of the inbound callleg, receive, from the second media server port, a first outbound callleg portion of an outbound call leg, transmit, to a destination device,a second outbound call leg portion of the outbound call leg, bridge thefirst inbound call leg portion to the second outbound call leg portion,the bridging causing the media server to be removed from thecommunication session, and reconnect the inbound call leg to the firstmedia server port and the outbound call leg to the second media serverport in response to detecting a dual tone multifrequency (DTMF) signal.14. The system of claim 13, where the media server disconnects the firstmedia server port from the inbound call leg and the second media serverport from the outbound call leg.
 15. The system of claim 13, where theDTMF signal is associated with at least one of a re-originate requestassociated with a pre-paid calling card, a take back and transferrequest associated with a calling session, or an enhanced call routingrequest.
 16. The system of claim 13, further comprising: adevice-implemented service controller for sending an INVITE request tothe media server to facilitate establishing the calling session.
 17. Thesystem of claim 13, further comprising: a device-implemented interactivevoice response system operatively associated with the media server forprocessing the inbound call leg.
 18. The system of claim 13, where themedia firewall further comprises: a processor to monitor the firstinbound call leg portion or the second outbound call leg portion for aparticular dual tone multifrequency (DTMF) signal.
 19. A method forprocessing a call on a network, comprising: receiving, at a secondnetwork device having an interactive voice response (IVR) device, aninbound call leg, from a caller, via a first network device; processingthe inbound call leg using the IVR device; generating, by the secondnetwork device, an outbound call leg based on the processing of theinbound call leg, where the outbound call leg connects the caller to adestination; transmitting the outbound call leg to the first networkdevice; handing off, from the IVR device to the first network device,the inbound call leg, in response to a BYE request associated with theinbound call leg, and handing off the outbound call leg, in response toa BYE request associated with the outbound call leg, where the inboundcall leg and the outbound call leg are subsequently dropped; detecting,by the second network device, a dual tone multifrequency (DTMF) signal;and causing at least one of the inbound call leg or the outbound callleg to be reestablished with the IVR device in response to detecting theDTMF signal.
 20. The method of claim 19, further comprising: receiving,at the second network device, a handoff message from a servicecontroller prior to handing off the inbound call leg and the outboundcall leg, the handoff message causing the first network device to bridgethe inbound call leg and the outbound call leg.
 21. The method of claim20, where the handoff message is a session initiation protocol message.22. The method of claim 19, further comprising: receiving, at a servicecontroller, an INVITE request associated with the caller, the INVITErequest for initiating the inbound call leg.
 23. The method of claim 19,where the IVR device is associated with a contact center.
 24. The methodof claim 19, where at least one of the inbound call leg or the outboundcall leg is established with the IVR device via the second networkdevice.
 25. The method of claim 19, where the inbound call leg isassociated with a pre-paid calling card.